home *** CD-ROM | disk | FTP | other *** search
/ Ham Radio 2000 / Ham Radio 2000.iso / ham2000 / satellit / pacdoc / info.txt < prev    next >
Text File  |  1994-08-22  |  7KB  |  193 lines
  1.  
  2.  
  3. From      : g0k8ka
  4. Title     : UO-14 Whole Orbit Data
  5. Keywords  : UO14 WOD TELEMETRY
  6. Uploader  : G0K8KA
  7. Uploaded  : Mon Jan 21 11:45:55 1991
  8. __________________________
  9.  
  10.                      UoSAT SPACECRAFT DATA SHEET
  11.  
  12.                         UNIVERSITY OF SURREY
  13.                       Guildford, Surrey GU2 5XH
  14.                  Tel: 0483-509143    FAX: 0483-34139
  15.  
  16.            WOD ON THE UOSAT-3 PACSAT COMMUNICATIONS EXPERIMENT
  17.  
  18. The PCE can conduct Whole Orbit Data surveys much like those supported by
  19. previous UoSAT onboard computers, but with some enhancements. The PCE
  20. Housekeeping Integration Task can sample up to 3 WOD surveys
  21. simultaneously, and the sample rate of a survey can be any value from 1
  22. second upward.
  23.  
  24. The PCE stores WOD and other information in an internal solid-state file
  25. store. WOD surveys are stored in binary files with Standard PACSAT File
  26. Headers (described in a separate document called PACSAT File Header
  27. Definition). As indicated in that document, the <file_type> in the header
  28. of a UoSAT-format WOD file is 3.
  29.  
  30. WOD files in the PCE file store are named using the following convention:
  31.  
  32. wdMMDDNN
  33.  
  34. wd - indicates that the file is a whole-orbit data file.
  35. MM - is replaced by a two digit month number, starting with 01 for January.
  36. DD - is replaced by a two digit day of the month.
  37. NN - is replaced by a two digit survey number, starting each day at 0.
  38.  
  39. For example, the first whole orbit data survey taken on the 3rd of February
  40. will be in file a file named "wd020300".
  41.  
  42. WOD files can be downloaded using the UoSAT-3 file server or received
  43. passively using the PACSAT Broadcast Protocol. These procedures are
  44. described in two documents: PACSAT Broadcast Protocol and PACSAT Protocol:
  45. File Transfer Level 0.
  46.  
  47. BINARY FILE FORMAT
  48.  
  49. Once a WOD file has been downloaded and its PACSAT file header removed, the
  50. file body contains a WOD survey in the standard binary format defined
  51. below.
  52.  
  53. (Data structures are described in a C-like syntax defined in the document
  54. PACSAT Data Specification Standards.)
  55.  
  56. All multi-byte values are stored least significant byte first.
  57.  
  58. 'long' is 4 bytes
  59. 'int'  is 2 bytes
  60. 'char' is 1 byte
  61.  
  62. WOD files begin with a WOD_HEADER structure.
  63.  
  64. WOD_HEADER {
  65.   unsigned long start_time;
  66.   unsigned long end_time;
  67.   int sample_period;
  68.   unsigned char number_of_channels;
  69. }
  70.  
  71. The header is followed by the channel numbers, each one stored as an
  72. unsigned char (e.g. a single byte).
  73.  
  74. <start_time> is the start time of the WOD survey, an unsigned 32-bit binary
  75. integer counting the number of seconds since Jan 1 1970.
  76.  
  77. <end_time> is the ending time of the WOD survey, time encoded as above.
  78.  
  79. <sample_period> is the number of seconds between samples in the survey.
  80.  
  81. <number_of_channels> is an 8-bit unsigned binary integer telling how many
  82. channels were in the survey.
  83.  
  84. The following <number_of_channels> bytes are the channel numbers
  85. themselves.
  86.  
  87. This header is followed by the data samples from the survey. Each data
  88. sample contains <number_of_channels> channel values. The channel values are
  89. stored as unsigned 16-bit integers. Within each sample the channel values
  90. are in the same order as specified in the WOD_HEADER. That is, if the wod
  91. header says that channels 12, 13 and 22 are being sampled, each sample in
  92. the file will be three 16-bit integer values, the first from channel 12,
  93. the second from channel 13 and the third from channel 22.
  94.  
  95. For example, here is the beginning of a survey taken on the UO-14
  96. simulator, where the actual telemetry values have been replaced by their
  97. channel numbers (e.g. reading telemetry channel 1 always returns 1).
  98.  
  99. The survey started at 0x26495e00, ended at 0x26495e78, was sampled every
  100. 0x0001 seconds, contained 0x04 channels and those channels were channels 01
  101. 02 03 and 04. The first two samples from the survey are then included.
  102.  
  103. 00 5E 49 26 78 5E 49 26 01 00 04 01 02 03 04 01
  104. 00 02 00 03 00 04 00 01 00 02 00 03 00 04 00
  105.  
  106.  
  107.  
  108.  
  109. From: G0SUL 21-4-93
  110. ~~~~~~~~~~~~~~~~~~~
  111. Sorry for the short-notice reload of UO-22. Full operation was restored
  112. after only one interrupted orbit.
  113.  
  114. The 20 April reload of UO-22 brings in some minor new features.
  115.  
  116. 1)  "Sked", which produces a periodic status message, is a facility
  117. which allows the command station to schedule command operations at
  118. any time in the future. It creates log files which will be type 216,
  119. and are of no interest to users.
  120.  
  121. 2)  PBP, the broadcast server has had some new features added.
  122.     
  123. 2.1) CL files
  124.  
  125. The server can now keep track of all the stations who have issued
  126. broadcast requests each day. This information is kept in RAM and
  127. written to a file once per day. The file will be named CLyymmdd and
  128. will have file type 217. The format of the file is an array of 6-byte
  129. strings. There will be a maximum of 400 callsigns in this array (at
  130. the moment.)
  131.  
  132. 2.2) BL files
  133.  
  134. The BL file data structure has been extended and the BL file format
  135. has been changed slightly. As previously, everything is stored in 
  136. log records:
  137.  
  138.        <length> <data>
  139.  
  140.        <length> is an integer telling the number of bytes in <data>
  141.        
  142.        From now on, there will be a record at the beginning of the
  143.        file giving the file format version. This record will have 
  144.        length two and the <data> field will be an integer telling 
  145.        the version of the log file. The present version is number 2.
  146.  
  147.        The remaining records in the file have BL structures as <data>
  148.  
  149.         /* BL structure for keeping statistics. Cleared hourly. */
  150.         struct STAT_STRUCT {
  151.           /* Time at which log entry was written. */
  152.           time_t log_time;
  153.  
  154.           /* command counters */
  155.           long nHolefills;
  156.           long nStartFile;
  157.           long nEndFile;
  158.  
  159.           long nNoFile;   /* No -2 */
  160.           long nNoRoom;   /* No -1 */
  161.           long nNotOK;    /* No -3 */
  162.  
  163.           /* nb are byte counters */
  164.           long nbRequested;    /* bytes in all requests added to queue */
  165.           long nbOverwrite;    /* removed by another request from same stn */
  166.           long nbUnfresh;      /* removed from queue after 10 minutes */
  167.           long nbPfhErr;       /* removed because PFH couldn't be read. */
  168.           long nbFopenErr;     /* removed because file couldn't be opened. */
  169.           long nbEnd;          /* removed from queue by file end commands */
  170.           long nbTransmitted;  /* actually transmitted */
  171.  
  172.           long nhRequested;  /* holes in hole fill requests */
  173.                              /* (not directory fills) */
  174.  
  175.           long nDirReqs;     /* dir fill requests */
  176.           long nbDirTxd;     /* bytes of dirs transmitted */
  177.  
  178.           /* ticks Count time devoted to various actions */
  179.           /* a tick is 10 msec */
  180.           long ticksDir;  /* spent sending directories */
  181.           long ticksData; /* spent sending data */
  182.  
  183.           /* Count calls heard this hour. */
  184.           int CallsHeard;
  185.         };
  186.  
  187. The BL logs are written roughly every hour, though this can be changed
  188. by ground command. A log will always be written so that the
  189. ticksData, TicksDir, nbDirTxd and nbTransmitted are consistant with
  190. one another. I.E. you can calculate dir and data throughput using the
  191. ticks numbers.
  192.  
  193.